Apparatus and system for object-based storage solid-state device

ABSTRACT

An object-based storage system comprising a host system capable of executing applications for and with an object-based storage device (OSD). Exemplary configurations include a call interface, a physical layer interface, an object-based storage solid-state device (OSD-SSD), and are further characterized by the presence of a storage processor capable of processing object-based storage device algorithms interleaved with processing of physical storage device management. Embodiments include a storage controller capable of executing recognition, classification and tagging of application files, especially including image, music, and other media. Also disclosed are methods for initializing and configuring an OSD-SSD device.

CLAIM OF PRIORITY

This application is a continuation of co-pending U.S. Ser. No.16/027,332 filed Jul. 4, 2018, which is a continuation of U.S. Ser. No.15/199,674 filed Jun. 30, 2016 (now U.S. Pat. No. 10,025,705), which isa continuation of U.S. Ser. No. 13/775,216 filed Mar. 2, 2013 (now U.S.Pat. No. 9,824,006), which is a continuation of U.S. Ser. No. 13/118,418filed May 28, 2011 (now U.S. Pat. No. 8,402,152), which is acontinuation of U.S. Ser. No. 12/319,096 filed Dec. 31, 2008 (now U.S.Pat. No. 7,970,919), which claims priority to U.S. Ser. No. 61/011,899filed Jan. 22, 2008 (now expired), and this application is acontinuation-in-part of Ser. No. 11/891,741 filed Aug. 13, 2007 (nowabandoned), all incorporated by reference herein and all benefits of allpriorities hereby claimed.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document may contain materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

This invention relates to object-based storage devices (OSDs), and moreparticularly to object-based storage systems.

BACKGROUND

The subject matter discussed in the background section should not beassumed to be prior art merely as a result of its mention in thebackground section. Similarly, a problem mentioned in the backgroundsection or associated with the subject matter of the background sectionshould not be assumed to have been previously recognized in the priorart. The subject matter in the background section merely representsdifferent approaches, which in and of themselves may also be inventions.

In various conventional storage systems, rotating magnetic media isused. While the density of such rotating media has increased with demandfor storage, the mere fact that the system has mechanically moving partsmakes the system inherently subject to reliability problems, andinherently slow, slow, at least relative to the speed of movingelectrons. Conventional approaches to mitigating the inherentlimitations of rotating storage media have included the creation ofarrays of redundant independent disks (RAID). Many advances inRAID-related technologies have resulted in a well understood corpus oftechniques for RAID that address reliability and speed.

Concurrent with advances in storage subsystems, are advances in thetaxonomy of stored items. Whereas traditionally a stored item is viewedby the operating system as just a sequence of blocks of binary data,prescient operating system design considers stored objects as havingmany more attributes than merely a sequence of blocks of binary data. Ofcourse with a more specific taxonomy of stored items comes additionalcapabilities (and speed requirements) for the operating system topre-process data before presenting to a user or to an application.Commercially viable solid-state memory systems based on DRAM, while muchfaster than rotating media, exhibit another set of limitations,including (depending on the specific technology or techniques employed)volatility and cost.

Meanwhile, trends in manufacturing of certain solid-state memory devicesportend higher densities, inherently higher reliability, and higherspeeds, while delivering functionality at lower power and lower costssuch as NAND flash memory. However, commercially available consumergrade external storage devices have limited storage host attachinterfaces (e.g. USB or 1394), and controllers that are typicallyincluded with FLASH devices are only very modest in capability.

Even given the viable storage technologies, access and transfer speedsare still far slower than users accept when the aforementionedpre-processing techniques are employed. Moreover in many commercialembodiments, multiple interfaces (especially interfaces of differingtypes) are preferred.

These and other limitations foster the notion to combine the concepts ofobject-based storage techniques with high-performance solid-state basedstorage. Consideration of object-based storage algorithms executing onstorage host attach interfaces, together with solid-state memorysystems, results in an avalanche of ideas and inventions which are thesubject matter of the detailed descriptions of embodiments herein.

SUMMARY

The invention provides for a storage physical interface and ischaracterized by a control module capable of processing object storagedevice algorithms. The storage physical interface is characterized by acontrol module capable of processing object storage device algorithmsand is further characterized by including at least one solid-statenon-volatile memory chip array.

In accordance with embodiments, there are provided techniques forproviding multiple interfaces in a solid-state based storage systememploying OSD techniques. Embodiments include providing for multipleinterfaces in a solid-state device (SSD) storage system within afreestanding storage cabinet, or in a desk side chassis, or in anindustry-standard drawer-type form factor, or in a consumer device (e.g.digital camera, smartphone, handheld game console), or even inminiaturized or custom form factors.

Any of the above embodiments may be used alone or together with oneanother in any combination. Inventions encompassed within thisspecification may also include embodiments that are only partiallymentioned or alluded to or are not mentioned or alluded to at all inthis brief summary or in the abstract. Although various embodiments ofthe invention may have been motivated by various deficiencies with theprior art, which may be discussed or alluded to in one or more places inthe specification, the embodiments of the invention do not necessarilyaddress any of these deficiencies. In other words, different embodimentsof the invention may address different deficiencies that may bediscussed in the specification. Some embodiments may only partiallyaddress some deficiencies or just one deficiency that may be discussedin the specification, and some embodiments may not address any of thesedeficiencies.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings like reference numbers are used to refer tolike elements. Although the following figures depict various examples ofthe invention, the invention is not limited to the examples depicted inthe figures.

FIG. 1A illustrates a block diagram of an environment where an apparatusfor providing a solid-state based storage device with multipleinterfaces might be used, according to one embodiment.

FIG. 1B illustrates a block diagram of a software stack for providing asolid-state based storage array with multiple interfaces, according toone embodiment.

FIG. 2 illustrates a block diagram of an embodiment of a solid-statebased storage device.

FIG. 3 illustrates an embodiment of a controller card as an exemplaryimplementation of a solid-state based storage device with multipleinterfaces.

FIG. 4 illustrates exemplary configurations of an apparatus forproviding a solid-state based storage device, according to oneembodiment.

FIG. 5 illustrates a block diagram of an embodiment of a networkedenvironment wherein an apparatus for providing a solid-state basedstorage device with multiple interfaces might be used.

FIG. 6 illustrates a method for configuring a solid-state based storagedevice, according to one embodiment.

FIG. 7 depicts a storage subsystem connected to a host, according to oneembodiment.

FIG. 8 depicts an exemplary configuration of an object-based,solid-state based storage device, according to one embodiment.

FIG. 9 illustrates a method for configuring a solid-state based storagedevice, according to one embodiment.

FIG. 10 illustrates a method for executing a command to an object-basedstorage device, according to one embodiment.

DETAILED DESCRIPTION General Overview

Systems and methods are provided for an apparatus for providing asolid-state based storage device with multiple interfaces. Apparatus andmethods are disclosed herein, with emphasis on disclosure of embodimentsto provide features related to a solid-state based storage device withmultiple interfaces and techniques to enable additional enhancedservices in conjunction with the traditional use of a storage device. Inaccordance with embodiments, there are provided techniques for providingmultiple interfaces in a solid-state based storage system employing OSDtechniques. Embodiments include providing for a solid-state device (SSD)storage system within a freestanding storage cabinet, or in a desk sidechassis, or in an industry-standard drawer-type form factor, or in aconsumer device (e.g. digital camera, smartphone, handheld gameconsole), or even in miniaturized or custom form factors.

FIG. 1A illustrates a block diagram of an environment where an apparatusfor providing a solid-state based storage device with multipleinterfaces might be used. In particular, FIG. 1A depicts a computersystem 102 (e.g. desktop personal computer, desk side personal computer,server, DVR, NVR, PVR, media server, game console such as an Xbox™ orWii™, entertainment center, or any other consumer device employingnon-volatile memory, digital camera, smartphone, handheld game console,mobile handheld device, etc.) connected to a solid-state based storagedevice 104 through at least one interface in operation throughconnection 105. Strictly as an option, the solid-state based storagedevice 104 may feature multiple solid-state disk drives 122 ₁ through122 _(N). Embodiments of the solid-state based storage device 104 mayinclude multiple interfaces 118 ₁ through 118 _(N), capable to serve atleast two distinct input-output interface types. Embodiments of thesolid-state based storage device 104 may include multiple controllers120 ₁ through 120 _(N). The computer system may include a CPU or GPU106, and may further include random access memory 108, provided asinternal or external random access memory or both. In some embodiments,the computer system 102 may contain a local hard disk drive (HDD)storage. As an optional feature, the computer system 102 may contain ahost bus adapter 112 and a client agent 114. As will be described in thefollowing, the host bus adapter may be as simple as a physical layerinterface, or it may be more complex, involving both firmware andsoftware, or any degree of complexity or simplicity. Similarly, theclient agent 114 may be implemented in or on any element included in thecomputer system 102 that is capable of executing software or firmware.In this exemplary environment, the components 102 and 104 each includefirmware or software or both as is presently described.

FIG. 1B depicts a block diagram of a software stack. Strictly as anoption in some embodiments, software applications 152 execute oncomputer system 102 possibly using any services as may be provided byone or more operating system (OS) kernels 154 ₁-154 _(N). The OS kernel,in turn may use any services as may be provided by the drivers 156 ₁through 156 _(N).

In addition to the aforementioned software stack components 152, 154,and 156, the solid-state based storage device with multiple interfaces104 may itself include a collection of software or firmware, which maybe organized into multiple images or multiple instances as depicted inelements 158 ₁ through 158 _(N). Additionally, there may be firmware orsoftware or even an entire stack of software embedded in, or executingon, or adapted to execute on or in or with the one or more solid-statedisk drives 122.

FIG. 2 shows an example embodiment of a solid-state based storage device104 as shown in FIG. 1, and similarly again in the embodiment of FIG. 2.In the method 200, the embodiment includes a carrier or chassis 202which may be a physical chassis, or a motherboard, or a daughter-card orany other printed circuit board (PCB). The chassis 202 serves to orientand connect one or more controllers 204, 206 to an array of solid-statebased storage devices 210. In some embodiments, there may be a pluralityof controllers 204, 206 configured to provide enhanced reliability. Asone skilled in the art will readily recognize, the techniques andcapabilities employed in a RAID array of spinning drive elements can besimilarly employed in the situation where solid-state based storagedevices are employed as RAID elements of RAID sets. In the exampleshown, a controller 204 is in communication with every element in thearray of solid-state based storage devices 210. Also as shown, strictlyas an option to provide redundancy, a second or nth controller 206 is incommunication with every element in the array of solid-state basedstorage devices 210. The solid-state based storage devices 210 may beimplemented by using one or more types of solid-state based storagedevices, including flash-based SSDs (whether NAND or other flashtechnology), or other solid-state based storage devices, or whether ornot the SSDs include a SATA, or SATA2, or SAS, or IDE, or otherinterface.

FIG. 3 illustrates a system 300 for an interface 118. The exemplaryembodiment shown includes a plurality of input-output interfaces, 304,306, 308, as shown. Each of the plurality of input-output interfaces304, 306, 308 are in communication with at least one input-outputcontroller 310 adapted for implementation of the specific type or typesof input-output carried out over the plurality of interfaces 304, 306,308. In this embodiment, any known input-output interface may beimplemented by the input-output interfaces and input-output controller,and may implement at least two interfaces, including, eSATA, 802.3x,Ethernet, 802.11a, 802.11b, 802.11g, 802.11n, USB, USB 1.x, USB 2.x,IEEE 1394, Firewire™, PCI Express (per PCI-SIG) using internal orexternal cabling or any other known communication system. One or more ofthese interfaces 304, 306, 308 may be enabled or disabled at any time.Or, one or more connections, whether physical or logical connections maybe concurrently enabled at any time. With respect to wireless interfaces(e.g. 802.11x) the encryption security may be enabled or disabled.

The signals 309 are carried out over connections (whether physicalconnections or logical connections) to and from input-output controller310 and to and from the plurality of interfaces 304. The input-outputcontroller serves to implement aspects of the communication protocolincluding (optionally) aspects of the data link, network layer,transport layer, session layer, presentation layer, application layer,and/or aspects of routing protocols. Moreover, the input-outputcontroller 310 is adapted to communicate over signals 312 to at leastone storage controller 314.

Strictly as an option, the controller 302 may implement a processor 316separate from the input-output controller 310 and storage controller314. Such a processor 316, if present may be in communication with theinput-output controller 310 and/or the storage controller 314. To theextent that the aforementioned aspects of the communication protocol arenot implemented by the input-output interfaces 304, 306, 308 and/orinput-output controllers 310, the processor 316 may be employed toimplement aspects of the protocol. Examples of the input-output protocolmay include network attached storage (NAS) and/or interne small computerstorage interface (iSCSI). Additionally, to the extent that theaforementioned aspects of the communication protocol are not implementedby the input-output interfaces and/or input-output controllers 310, theprocessor 316 may implement or emulate some of all aspects of CIFS orNTFS, or NFS or any other file system.

Strictly as an option, the controller 302 may implement a processor 316separate from the input-output controller 310 and storage controller314. Such a processor 316, if present may be in communication with theinput-output controller 310 and/or the storage controller 314. To theextent that the aforementioned aspects of the communication protocol arenot implemented by the input-output interfaces 304, 306, 308 and/orinput-output controllers 310, the processor 316 may be employed toimplement some or all aspects of a variety of storage applications.Strictly as an option the controller 302 may be implemented ascollection of discrete components combined on a carrier, or may beimplemented as a single semiconductor platform. It should be noted thatthe term single semiconductor platform may also refer to multi-chipmodules. Of course, the various modules may also be situated separatelyor in various combinations of semiconductor platforms or carriers.

In the specific case of implementation of aspects of a variety ofstorage applications via execution of software or firmware in or on thestorage controller 314 and/or in or on the processor 316, the controller314 and/or the processor 316 serves to communicate with client agent 114to carry out the aforementioned aspects of a variety of storageapplications.

One or more storage controller(s) 314 is capable of running in non-RAIDand RAID mode with different levels (0, 1, 3, 5, 6, 10), and interfacesto at least one SSD interface 320 over signals 318. In someimplementations there will be exactly one SSD interface 320. In otherimplementations, there may be more than one SSD interfaces 320. Inpreferred embodiments the number of SSD interfaces is defined by thespecific RAID configuration implemented

The elements 330 ₁ through 330 _(n) as shown in the exemplary embodimentof FIG. 3 are solid-state storage devices (SSD) and are individually incommunication to an interface 320 over signals 322. The SSDs 330 ₁through 330 _(n) may all be identical instances of the same SSD, or theymay be arbitrarily sized and configured, so long as they properlyconform to the interface characteristics of the corresponding interface320. As an option, the storage controller 314 may communicate with anexpansion port 336 for provision of storage capacity in addition to thestorage capacity of SSDs 330 ₁ through 330 _(n).

FIG. 4 shows a possible configuration of a storage enclosure. Thefree-standing storage enclosure shown in FIG. 4 is strictly an option,and other embodiments of a solid-state based storage device are not onlypossible, but also disclosed herein. The system 400 includes afree-standing enclosure 401, and further includes at least one interface418. In some configurations, of the enclosure 401, the enclosure isadapted with one or more bays which conform to all mechanical,electrical, and other requirements to comport with the SATA2 hard diskcarrier form factor. See element 402 ₁ through 402 _(n). Strictly as anoption, one or more of such bays, or bays of a form factor other thanSATA2 hard disk carrier form factor are populated with one or more SSDdevices. It must be emphasized that the form factor of any existing orprophetic SSD device may be (either individually or in some physicalcombination) of a different size than the devices intended to populatethe SATA2 bay; accordingly, an arbitrary number of SSD devices can bearranged, connected, mounted, stacked, or otherwise adapted to fit intothe bays 402 ₁ through 402 _(n) As an alternative embodiment, theenclosure 401 might be electrically and mechanically designed to fitinto a handheld consumer device (e.g. digital camera, smartphone,handheld game console), in which case the interface 418 might be aCompact Flash interface, a SATA interface, a PCI-Express interface, anATA interface, an IDE interface, or even a wireless interface adaptedfor memory accesses.

The system 400 may be adapted with one or more bays which conform to anymechanical, electrical, and other requirements to comport with the driveform-factors other than a SATA form-factor.

Strictly as an option the method of 400 or other embodiments discussedherein may include an expansion interface 406 suited to comport to oneor more storage device standards, including SATA, SATA2, wired Ethernetincluding gigabit Ethernet and 10 gigabit Ethernet. As an option, thisexpansion interface 406 is provided to permit expansion of storagecapacity using storage devices attached to the expansion interface 406.Alternatively, expansion 406 might be a port of the same (or different)type as the interface 418, and be adapted for memory capacity orperformance expansion.

In some embodiments of a solid-state based storage device, the enclosuremay contain one or more printed circuit boards (PCBs), daughter-cards,sub-chassis, carriers 408 ₁ through 408 _(n) designed or adapted toprovide a physical mounting as well as electrical connectivity with, andto, and from any components used in elements 402 ₁ through 402 _(n),406, and/or interface 418.

As mentioned in the discussion herein regarding FIG. 4, thefree-standing chassis embodiment is one of a multitude of possiblephysical design configurations. In addition to a multitude offree-standing chassis configurations, the solid-state based storagedevice may be enclosed in other chassis as may be present for enclosureof elements 102, or 104 of FIG. 1A. In fact, inasmuch as the solid-statebased storage device of FIG. 2 or FIG. 3, or FIG. 4 can be partitioned,some portion of the solid-state based storage device may be enclosed inone chassis among 102, 104, while the remaining portions may be enclosedin a different chassis.

While FIG. 4 depicts the aspect ratio of a ‘tower’ enclosure, theenclosure need only be as large as is needed to package the elements ofsystem 300. In one such packaging option, the size and aspect ratio issimilar to the size and aspect ratio of a 3.5 inch hard disk drive(HDD). In some cases, strictly as an option the aforementioned packagemay fit mechanically and electrically into a 3.5 inch HDD bay.Similarly, in one packaging option, the size and aspect ratio is similarto the size and aspect ratio of a 2.5 inch hard disk drive (HDD). Insome cases, strictly as an option the aforementioned package may fitmechanically and electrically into a 2.5 inch HDD bay. In yet anotherembodiment the package may conform to the 3.5 inch or 2.5 inch drive bayphysical requirements, and yet be free-standing. In yet anotherembodiment, the elements of system 300 might be packaged into a formfactor only as large as required to house the needed elements.

Returning attention to FIG. 3 as is herein disclosed, the input-outputcontroller 310 communicates to and from one or more of the plurality ofinterfaces 304, 306, 308. Accordingly the input-output controller 310may implement a method to select from the plurality of interfaces 304,306, 308. One skilled in the art will recognize that whereas selectionof hard-wired interfaces has been traditionally performed using aphysical or logical multiplexor, the inclusion of the aforementioned oneor more wireless protocols implies that a method to select not only theinterfaces from among the plurality of interfaces but possibly also fromone or more specific wireless networks that may be reachable over theplurality of interfaces. Accordingly the method 600 of FIG. 6 is hereindisclosed.

FIG. 5 illustrates an environment wherein an apparatus for providing asolid-state based storage device with multiple interfaces might be used.In this exemplary network topology, one or more solid-state basedstorage devices 502 and 504 are in communication with one or more CPUs506 or GPUs 508 or other computing subsystem such as a server, orpersonal computer or any variety of handheld consumer devices. Such apersonal computer or server or CPU 506 or GPU 508 contains a clientagent 507 capable to handle at least one function involved in thecommunication carried out over the path 522. In some environments, theone or more CPUs 506 or GPUs 508 may optionally be connected to network526. Further, in some environments, the one or more CPUs 506 or GPUs 508may optionally be connected to storage device 502 via connection 525which is distinct from the network connection 524.

The interconnect fabric 510 may operate to execute multiple physicallayers, multiple link layers, multiple protocols and multiple modes ofsession management. In the embodiment shown, a storage device 502 may bein communication through an interconnect network 510 via an interface520 using a connection 518. As shown, concurrently a second or Nthsolid-state based storage device 504 may be in. communication through aninterconnect network 510 via an interface 519 using a connection 525.Strictly as an option, yet another storage apparatus 512 which may notbe a solid-state based storage array may be present in the environment.

In one embodiment plural solid-state based storage devices may bepresent and used as at least two nodes in said network topology.Strictly as an option, a network topology with plural solid-state basedstorage devices may implement secondary backup storage discussed infra.Moreover, the solid-state based storage device may be shared by one ormultiple users as primary, backup, or as secondary backup storage, or asmedia storage, or as shared storage of any type of data or media files.

FIG. 6 depicts a method to select a subset of user-specified interfacesfrom a plurality of possible interfaces. Specifically, the method 600begins by accepting user-specified preferences. See operation 602. Theoperation 602 may employ one or more techniques, including use of aprofile, use of a GUI, use of an import filter, or use model heuristics,and/or use of any known technique to confirm with or derive from theuser the user's preferences. The method 600 continues by mapping theuser preferences to the available input-output interfaces, resulting inan input-out controller configuration. See operation 604. Next, theresulting input-output controller configuration is mapped to theavailable storage controller configurations. That is, the operation 606operates by mapping the input-output controller configuration result ofoperation 604 to the storage controller.

Some examples of the operation 602 may include accepting user-specifiedpreferences from a GUI or configuration file. In some embodiments, aconfiguration file with default values of settings and preferences isprovided and may or may not be modified by the user. Specific cases ofuser-specified input may include user selection of the location forprimary storage, search characteristics for tags in an OSDconfiguration, tag creation options, selection of adaptive taggingoptions, option selection for capturing specific media types in specificOSD formats, etc. In this case, the default preference may be to move orotherwise store data found on any local storage device to the SSD, andhenceforth use the SSD as primary storage. Another user selection mayinclude options for backup. More specifically, through strictly as anoption, the user may specify a variety of backup configuration options,including what data to backup, the frequency of backup, the namingconventions to be used in naming backed-up data, and the specific targetlocation on one or more SSDs. Another option is that the SSD storagedevice may utilized for media sharing and being accessed by multipleusers (CPU or GPU based) via a network. In this case any user canutilize the device as primary, back-up, or secondary storage. Inexemplary cases involving more than one SSD storage device volumes,operation 602 captures user options regarding secondary backup storagewhere a second or nth copy of backed-up data is stored on one of moresecondary SSD storage device volumes. Of course a secondary SSD storagedevice volume may include multiple SSDs, or it may include multiple SSDstorage arrays, or it may merely include a directory or other file on asingle SSD.

FIG. 7 shows a conventional solid-state based storage device 704connected to a host system 701 via a storage physical layer interface703. Generally speaking, conventional solid-state based storage devicesemploy a controller for processing algorithms for physical storagedevice management (e.g. wear-leveling) 718. Also, conventionalsolid-state based storage devices contain one or more solid-statenon-volatile memory devices (e.g. NAND or other flash memory devices).

FIG. 8 shows a method 800 including a host system 802 which employs apartition for executing applications 806, a system call interface 807,an OSD storage driver 801, an OSD call interface 808, and aninter-system physical layer interface 809 (e.g. SATA, SAS, PATA,Fibre-channel, SCSI, IDE, etc.) for communicating to/from an OSD-SSD 804over an inter-system communication media 810 (e.g. copper wire, fibre,or wireless media). The OSD-SSD in turn comprises a storage physicalinterface communication link 811, a control module capable of processingalgorithms for OSD 812 combined with processing of physical storagedevice management algorithms 818, and at least one group of solid-statenon-volatile memory devices 820.

In embodiments, the OSD-SSD controller (812) may be a uniprocessor or amulti-processor; in particular, the OSD algorithms and physical storagedevice management algorithms are adapted to execute on the same controlprocessor or processors 816. In one embodiment, the OSD algorithmsperform the storage management component which maps logical constructs(e.g. files or database entries) to the physical organization of thestorage media. In the OSD model, the logical constructs are called userobjects. In addition to mapping data, the storage management componentmaintains other information about the OSD objects that it stores (e.g.size, and usage quotas, and associated username) in attributes. The usercomponent may have the ability to influence the properties of objectdata through the specification of attributes (e.g. directing that thelocation of an object be in close proximity to another object or havesome higher performance characteristic) via mechanisms that are known inthe art.

In other embodiments the OSD algorithms operate on the data or theprotocol for communicating or processing data so as to implement mappingfunctions, storage functions, metadata definitions, assignment andstorage functions, and user-specific functions. In fact, in someembodiments the OSD algorithms are known only by a code that maps to aspecific implementation; for example a code of value “xyz123” might beredirected to an algorithm available via interne access at an addresssuch as http://abc.osdalgorithms/xyz123.

Of course, an OSD algorithm may be implemented in a single processor, orin multiple processors, or may even be implemented in multipleprocessors situated in different subsystems in communication with eachother across the inter-system media communication link 810.

In some embodiments, the partition for executing applications 806 may bea logical partition of an operating system such as user space, or it maybe a combination of partitions of an operating system including bothuser space and kernel space. In other embodiments, the partition mayitself be a processor or controller, or a plurality of processors orcontrollers. The partition as envisioned in various embodiments may bestrictly a virtual construction, and may in fact be comprised of anycombination of logical partitions and physical partitions, possiblyinvolving any number of processors or controllers.

The system call interface 807 of FIG. 8 may be the system interface asdelivered in any version of any known operating system, including anyversion or descendant of Microsoft Windows, any version or descendant ofUNIX or any version or descendant of Linux, or of any embedded operatingsystem, whether commercially available or not.

The OSD interface 808 is adapted to interface to the system callinterface 807 as well as the OSD interface 808 and further, as animplementation choice may be adapted to interface with the storagephysical interface 809. In embodiments, the OSD interface 808 may merelytransmit commands or information between the system call interface 807and the storage physical interface 809, or it may operate on theinformation before passing those commands or information.

The storage physical interface 811 may include any generation of SATA,SAS, PATA, Fibre-channel, SCSI, IDE, Compact Flash, PCI-Express, or evenUSB, IEEE, FireWire, Ethernet, Gigabit Ethernet, or any serial orparallel physical interface capable of transmission over electricallyconductive media or over light transmitting media or even over awireless medium, possibly using any one or more wireless standards (e.g.Bluetooth, 802.11, Wi-Fi, WiMAX, etc.).

In various embodiments, the inter-system physical layer interfacecommunication link 810 may be identical to the storage physicalinterface 811, or the inter-system physical layer interfacecommunication link 810 may include any combination of implementations ofstorage physical interface 811, or may include the use of othertechniques for inter-system connectivity.

The control module is capable of processing algorithms for the OSD 812.The algorithms may be adapted to make use of any OSD formats, or of anyportion or subset of the standard known as T10-OSD protocol format, alsoknown as the OSD T10-standard, and heretofore known by such aliasesincluding the shortened form, T10-OSD. Moreover, any portion orcombination of components or functions of the OSD-SSD 804 and/or thehost 802 may be fully or partially T10-OSD compliant.

The solid-state non-volatile memory devices 820 may be implemented invarious embodiments such as flash storage, or it may be implementedusing any known method for providing a non-volatile capability to anydigital storage device or media. Actual embodiments and envisionedembodiments include support for a wide range of storage media, includingNAND flash (all variants expressly including MLC and SLC) and othernon-volatile memory, regardless of the SSD technology employed andregardless of if the non-volatile characteristic is implemented usingthe charged gate technique or other techniques such as battery-poweredsemiconductor memory.

In exemplary embodiments, the OSD-SSD may employ a controller that is anembedded controller, a uniprocessor, or the controller may beimplemented as a multi-processor array of loosely- or tightly-coupledprocessors.

Once the host system and OSD-SSD are initialized, any command set perthe T10-OSD specifications may be executed (e.g. READ and WRITE). As anoption (but not a requirement or limitation), the READ command requeststhat the device server return data to the application client from thespecified user object, and the WRITE command causes the specified numberof bytes to be written to the specified user object at the specifiedrelative location. In other embodiments, and indeed in normal operationof exemplary embodiments, the READ and WRITE commands may take on anyother variations as are known in the art.

It is observed that for a broad class of stored objects, the object iswritten and thence retrieved, or searched, or filtered, or used in ajoin operation or in a projection, or used in any other manner inqueries many times. The asymmetric characteristic therein is known asasymmetric storage object access. As will be readily recognized by thoseskilled in the art, the apparatus and methods herein described supportasymmetric storage object access. In various embodiments, this asymmetryis exploited in processing of video files, music files, database files,emails, forms, and virtually any type of file intended to be retrievedmultiple times on the basis of some criteria capable of being formulatedinto a query. Stated in other terms, the act of writing a storage objectmay include pre-processing the file to produce tags, the tags then beingformatted as part of the object (including the data of file), and theact of reading the object (or group of objects) may include retrieval onthe basis of querying the tags or metadata or other aspects associatedwith the object (or group of objects).

FIG. 9 shows one embodiment of a method for initializing a device foruse in object-based storage. Using any computer coding techniques, themethod for configuring an object-based storage device onto a hostprocessor might comprise steps for determining the host systemcharacteristics (see operation 902); determining connected communicationOSD device characteristics (see operation 904); installing at least oneOSD interface onto the host (see operation 906); determining connectedcommunication device logical characteristics (see operation 908);configuring OSD interfacing requirements, possibly with user-specifiedconfigurations parameters, and possibly interactively with a userthrough a computer-user interface such as a GUI (see operation 910); andinitializing solid state devices (see operation 912). Of course thesteps included in system 900 can be performed in any particular order,or even in parallel, or even some in parallel and some serially.

Of course the steps for determining host system characteristics might beperformed by an instance of a CPU on the host system 802, and morespecifically by any one or more software code segments for an OSDinterface 808, an OSD storage driver 801, any part of a system callinterface 807 or transaction therethrough, or even from one or moreapplications running on host system 802. Alternatively, or incombination with the foregoing host-based components (808, 801, 807,806), one embodiment of a method for initializing a device for use inobject-based storage might include software code for an OSD interfacethat resides on an OSD-SSD device 804, including any one or morehierarchical blocks 811 or 816, or even in conjunction with code orinterfaces incorporated into flash devices 820.

In fact, it is reasonable, envisioned, and exemplified in FIG. 10 thatcode or interface hardware residing on the OSD-SSD 804 might beconfigured for accepting storage commands from a system call interface(see operation 1002) of a host 802, translating storage commands fromthe host into storage commands for an OSD-SSD device (see operation1004), initiating a second communication protocol between the host andthe OSD-SSD (see operation 1006), and communicating results fromexecution of the second protocol (see operation 1008) to the host 802.In some cases, translation of a storage command (or a combination ofstorage commands) from the host into storage commands for an OSD-SSDdevice might include translating onto a different protocol, and such adifferent protocol might in turn include expansion of a single protocolcommand into multiple protocol commands. Similarly, any module capableof performing the operation 1004 might receive multiple storage commandsfrom the host into fewer storage commands, or even a single storagecommand for an OSD-SSD device.

In another embodiment, the method 1000 for initializing a device for usein object-based storage might be employed to adapt legacy storagedevices to accept OSD commands. In particular, an OSD device might beconstructed by using a legacy device capable of responding to commandsover the inter-system communication link media 810. In generalizedcases, modifications might be made to such a legacy device in the formof software modification, or hardware modification to a storage physicalinterface 811, or modification to a controller 816 to includeOSD-specific command handlers, and/or modification to one or moremembers of the non-volatile storage device 820.

While the invention has been described by way of example and in terms ofthe specific embodiments, it is to be understood that the invention isnot limited to the disclosed embodiments. To the contrary, it isintended to cover various modifications and similar arrangements aswould be apparent to those skilled in the art. Therefore, the scope ofthe appended claims should be accorded the broadest interpretation so asto encompass all such modifications and similar arrangements.

I claim:
 1. A system comprising: a host system capable of executingapplications, the host system comprising at least an OSD call interface;and at least one inter-system physical layer interface between the hostsystem and an OSD-SSD device, wherein the OSD-SSD device has a storageprocessor capable of processing object storage device algorithmsinterleaved with processing of physical storage device managementalgorithms.
 2. The system of claim 1, wherein the OSD-SSD devicecomprises a plurality of non-volatile memory arrays.
 3. The system ofclaim 1 further comprising communication link media between the hostsystem and the OSD-SSD device, the communication link media between thehost system and the OSD-SSD device being capable of communicatingT10-OSD protocols.
 4. The system of claim 1 further comprising a hostsystem capable of executing code in a partition for executingapplications.
 5. The system of claim 1 further comprising a system callinterface.
 6. The system of claim 1 wherein the OSD call interfaceimplements a T10-OSD specification for OSD commands.
 7. The system ofclaim 1 wherein the at least one inter-system physical layer interfacebetween the host system and the OSD-SSD device is adapted to processcommunications over both USB and IEEE
 1394. 8. The system of claim 1wherein the at least one inter-system physical layer interface betweenthe host system and the OSD-SSD device is adapted to processcommunications over at least two of, USB, IEEE 1394, SATA1, SATA2, IDE,ATA, eSATA, SAS, PCI-Express, Compact Flash.
 9. The system of claim 1wherein the OSD-SSD device comprises at least two solid state storagedevices, and wherein the at least two solid state storage devices areconfigured in at least one of, RAID level 0, RAID level 1, RAID level 3,RAID level 5, RAID level 6, or RAID level
 10. 10. The system of claim 1wherein the at least one inter-system physical layer interface betweenthe host system and the OSD-SSD device includes an expansion port. 11.The system of claim 1 wherein the at least one inter-system physicallayer interface between the host system and the OSD-SSD device includesan interface capable to serve as primary storage to at least one of, apersonal computer, a server, a handheld device, a mobile device, a gameconsole, a DVR, an NVR, a PVR, a media server, or a notebook computer.12. The system of claim 1 wherein the at least one inter-system physicallayer interface between the host system and the OSD-SSD device includesan interface capable to serve as backup storage to at least one of, apersonal computer, a server, a handheld device, a mobile device, a gameconsole, a DVR, an NVR, a PVR, a media server, or a notebook computer.13. An apparatus comprising: a storage physical layer interface; aprocessor for processing a first set algorithms for physical storagedevice management interleaved with a second set of algorithms for OSD;and at least one solid-state non-volatile memory device.
 14. Theapparatus of claim 13 wherein the at least one solid-state non-volatilememory device comprises a flash memory device.